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REMARKS 

Applicant submits this paper in response to the Office's communication of November 
25, 2008. In that communication, the Office suggests that Applicant did not provide 
arguments with respect to claims 9, 19, and 3 1 . Applicant respectfully submits this paper in 
response to the Office's communication. 

Claims 1-39 are pending in this application. Claims 1,9, 19 and 31 are independent. 
Applicant proposes amending claims 1, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 26, 27, 28, 
31, 32, 33, 34, 35, 36, 37, 38, and 39. 

Claims 1-39 stand rejected under 35 U.S.C § 101 as be directed to non-statutory 
subject matter. 

Claims 31-39 stand rejected under 35 U.S.C. § 102 (b). Claims 1 - 15, 25 - 30, and 
38 stand rejected under 35 U.S.C. § 103 (a). 

Reconsideration in view of the above-listed amendments and the following remarks is 
respectfully requested. 

Interview Summary 

The undersigned wishes to thank Examiner Sciacca for granting the telephonic 
interview of August 4, 2008. 

During the interview, Applicants proposed amendments and arguments substantially 
consistent with those presented herein. Examiner Sciacca agreed to give further 
consideration to the arguments upon submission of a written response. 

Rejection Under 3 5 U.S.C. § 101 

Claims 1-39 stand rejected under 35 U.S.C § 101 as be directed to non-statutory 
subject matter. While not agreeing with the basis for the rejections, Applicant proposes 
amending the claims in order to advance prosecution. 

With respect to claims 1 , Applicant proposes to amend the claim to recite elements of 
a computing system in the recited method. With respect to claim 9, Applicant proposes to 
amend the claim to recite a computer-readable "storage" medium. With respect to claim 19, 
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Applicant proposes to amend the claim to recite steps performed at a computer device. 
Claim 3 1 has been amended to recite a method. 

Reconsideration and withdrawal of the rejections under 35 U.S.C § 101 is respectfully 
requested. 

Rejections under 35 U.S.C. § 102/103 

Claims 31-39 stand rejected under 35 U.S.C. § 102(b) as allegedly being anticipated 
by U.S. Patent 5,261,085 (the "085 patent"). 

Claims 1 - 4, 6 - 14 and 26 - 30 stand rejected under 35 U.S.C. § 103(a) as allegedly 
being unpatentable over the 085 patent in view of Paxos Made Simple ("Paxos") from 
Applicant's IDS dated December 30, 2003. 

Claims 5, 15 and 25 stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over the '085 Patent in view of Paxos in further view of U.S. patent publication 
2003/0227392 (the "392 Application"). 

Claim 38 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over the 
'085 Patent in view of U.S. patent publication 2002/01 12198 (the "198 Application"). 

Reconsideration is respectfully requested. 

Applicant notes in the patent application specification that: 

[I]n the event of conflicts, the Fast Paxos algorithm can, by 
performing the first phase of the standard Paxos algorithm, 
introduce more message delays than would have otherwise 
been present if the system 10 had been using the standard 
Paxos algorithm all along. Because conflicts can arise 
frequently in an environment in which more than once 
device may seek to act as a client , a reduced message delay 
consensus algorithm such as Fast Paxos may not provide 
the expected efficiencies unless it can continue operating 
properly in the face of conflicting client proposals, fl] 
[0108]). 

Applicant has therefore disclosed: 
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[A] system can implement a reduced message delay consensus 
algorithm that is conflict tolerant. Turning to FIG. 8a, an 
exemplary environment is shown comprising one client device 
20, and additional devices 11-15 that are both the constituent 
devices of the distributed computing system 10, and can act as 
clients of the system 10. Furthermore, as shown, each of the 
devices 11-15 and the client 20 can be assigned a client 
identifier. In one embodiment contemplated by the present 
invention, the constituent devices of the system 10 essentially 
vote for a combination of a proposed function, and the 
particular device that proposed the function. Thus, while a 
device might vote for a proposed function from one device, 
it might not vote for the same proposed function if it was 
proposed by a different device. As will be shown in more 
detail below, a reference to the identifier of the device 
proposing the function can help provide conflict tolerance. fl[ 
[0110]). 

Claim 1 

Claim 1 recites: 

A method for selecting a value in a distributed computing 
system, the method comprising: 

receiving at a computing device from a first client a 
first message comprising a first proposed value and a first 
client identifier corresponding to the first client ; 

voting at the computing device for the first proposed 

value; 

transmitting from the computing device a first 
indication of the voting for the first proposed value to one or 
more devices; and 

transmitting from the computing device a first result of 
the voting for the first proposed value to the first client, 

wherein the voting for the first proposed value, the 
transmitting the first indication of the voting for the first 
proposed value, and the transmitting the first result are not 
performed if a second message is received at the computing 
device from a second client , the second message comprising 
a second proposed value and a second client identifier 
corresponding to a second client, the second client identifier 
being more dominant than the first client identifier and the 
second proposed value having been previously voted for . 
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In order for a reference to anticipate this claim, or a set of references to render the claim 
obvious, the recited language and its combination in the recited method must be taught by the 
prior art. The undersigned respectfully submits that the cited references do not teach the 
emphasized language and cannot possibly teach or even suggest the recited method. 

The 085 patent discloses system for implementing a state machine. In the 085 patent, 
one process in a network of processes is chosen as the leader, and that leader is responsible 
for broadcasting state machine commands to other processes. (Abstract). Each command is 
broadcast through a numbered ballot and each process may either accept the command or not 
vote. (Abstract). In order for a command to be issued, the command must be voted for by a 
majority of the processes in the system. (Abstract). 

Thus, the 085 patent discloses a system wherein a single leader is designated 
to broadcast machine commands and the individual processes vote on the commands. In 
contrast to claim 1, the 085 patent does not disclose or suggest "receiving at a computing 
device from a first client a first message comprising a first proposed value and a first 
client identifier corresponding to the first client" and receiving "a second message ... at 
the computing device from a second client the second message comprising a second 
proposed value and a second client identifier corresponding to a second client." Rather, 
in the system disclosed in the 085 patent, it appears that messages are received from a single 
"client," namely the "leader." In other words, the 085 patent does not disclose or suggest 
receiving a first message "from a first client" and receiving a second message "from a second 
client." Indeed, the concept of selecting a leader teaches away from a system wherein 
messages may be received from a plurality of client devices; if there was a leader, messages 
would not be received from a plurality of client devices. 

Moreover, because the 085 patent appears to teach a single leader, and not receiving 
messages from a first client and a second client, the 085 patent cannot possibly teach "not" 
performing "the voting for the first proposed value, the transmitting the first indication of the 
voting for the first proposed value, and the transmitting the first result" if "a second message 
is received . . . the second message comprising a second proposed value and a second 
client identifier corresponding to a second client, the second client identifier bein2 more 
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dominant than the first client identifier and the second proposed value having been 
previously voted for." 

The Office also relies upon the Paxos algorithm for the rejection. Applicant 
acknowledges the existence of Paxos, and, in fact, discusses the Paxos algorithm and another 
algorithm known as the Fast Paxos algorithm in the present application. (See e.g., TffJ [0008] - 
[0013]). Applicant has noted that both algorithms have limitations. In particular, the Paxos 
algorithm introduces delays: 

However, the Paxos algorithm adds message delays between 
when a client sends a request for the distributed system to 
execute a command, and when the client receives the results 
from the execution that command. Specifically, even if the 
client transmits a request to a leader, and even if the leader has 
already learned of previously voted on proposals, and thus has 
completed the first phase of the Paxos algorithm, there can still 
be two or more message delays between the transmission of the 
request from the client, and the transmission of the results to 
the client. Furthermore, the Paxos algorithm can require the 
presence of a leader device that receives client requests and 
determines the appropriate functions to submit for a vote to the 
devices of the distributed computing system. Should such a 
leader device fail, a new leader may not take its place 
immediately, leaving the distributed computing system idle and 
the client waiting for a response to its requests. (Application, If 
[0011]). 

The Fast Paxos algorithm cannot tolerate a conflict among two or more clients. 

[T]he Fast Paxos algorithm cannot tolerate a conflict among 
two or more clients. Specifically, if two or more clients propose 
different functions at approximately the same time, the devices 
may be unable to choose between the different functions. In 
such a case, the system must stop using the Fast Paxos 
algorithm and return to the regular Paxos algorithm, with the 
leader beginning with the first phase, in an effort to resolve the 
discrepancy among the devices in the system. In such a case, 
the two or more clients that submitted the conflicting proposals 
may experience an even greater delay in receiving their 
responses than if the system had never attempted to operate 
using the Fast Paxos algorithm. (Application, If [0013]). 
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Applicant has developed a conflict tolerant reduced message delay consensus 
algorithm. In particular, Applicant discloses 

[A] system can implement a reduced message delay consensus 
algorithm that is conflict tolerant. Turning to FIG. 8a, an 
exemplary environment is shown comprising one client device 
20, and additional devices 11-15 that are both the constituent 
devices of the distributed computing system 10, and can act as 
clients of the system 10. Furthermore, as shown, each of the 
devices 11-15 and the client 20 can be assigned a client 
identifier. In one embodiment contemplated by the present 
invention, the constituent devices of the system 10 essentially 
vote for a combination of a proposed function, and the 
particular device that proposed the function. Thus, while a 
device might vote for a proposed function from one device, 
it might not vote for the same proposed function if it was 
proposed by a different device. As will be shown in more 
detail below, a reference to the identifier of the device 
proposing the function can help provide conflict tolerance . 
(Application, U [01 10]). 

In contrast to claim 1, Paxos does not disclose or suggest "receiving at a computing 
device from a first client a first message comprising a first proposed value and a first 
client identifier corresponding to the first client " and receiving "a second message ... at 
the computing device from a second client , the second message comprising a second 
proposed value and a second client identifier corresponding to a second client ." Rather, 
in the system disclosed by Paxos, proposals are received that are identified by a proposal 
number. The proposal numbers of Paxos do not comprise "a first proposed valued and a first 
client identifier corresponding to the first client" and "a second proposed value and a 
second client identifier corresponding to a second client." 

Furthermore, the Paxos algorithm does not disclose "not" performing "the voting for 
the first proposed value, the transmitting the first indication of the voting for the first 
proposed value, and the transmitting the first result" if "a second message is received . . . the 
second message comprising a second proposed value and a second client identifier 
corresponding to a second client, the second client identifier being more dominant than 
the first client identifier and the second proposed value having been previously voted 
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for." Rather, the Paxos algorithm relies on proposal numbers to determine what proposal to 
execute. Paxos does not determine or consider "the second client identifier being more 
dominant than the first client identifier." Indeed, the concept is entirely absent. 

The Office notes that Paxos discloses selecting a value in a network where there are 
multiple acceptors. (Office Action, p. 9). In particular, Paxos discloses that a value is chosen 
when a large enough number of acceptors accept the value. 

A proposer sends a proposed value to a set of acceptors. An 
acceptor may accept the proposed value. The value is chosen 
when a large enough set of acceptors have accepted it. 

But selecting a value because enough acceptors have accepted the value is not the same or 

even similar to "not" performing various activities "if" "a second message is received . . . the 

second message comprising a second proposed value and a second client identifier 

corresponding to a second client, the second client identifier bein2 more dominant than 

the first client identifier ." Rather, in Paxos, the selected value is based on whether a 

plurality of other acceptors have also accepted. The selection is not determined by whether a 

client identifier from a second client is more dominant than a first. 

The Office further notes that Paxos discloses an acceptor accepting a proposed value 
if it has not already responded to a request having a greater number. (Office Action, p. 9). 

An acceptor can accept a proposal numbered n if it has not 
responded to a prepare request having a number greater than n. 

Thus, Paxos teaches selecting a proposal based upon a proposal number. The referenced 

section of Paxos does not indicate that a proposal is selected based upon a client identifier as 

recited in the claim. There is not indication that a client identifier is even available to be 

considered in the Paxos algorithm. 

Therefore, because neither the 085 patent nor Paxos disclose the emphasized claim 
language, even in combination the references cannot be said to disclose or suggest the recited 
combination of claim 1 . 



Claim 9 
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Claim 9 recites: 

A computer-readable storage medium having computer- 
executable instructions for selecting a value in a distributed 
computing system, the computer-executable instructions 
performing steps comprising: 

receiving at a computing device from a first client a 
first message comprising a first proposed value and a first 
client identifier corresponding to the first client ; 

voting at the computing device for the first proposed 

value; 

transmitting from the computing device a first 
indication of the voting for the first proposed value to one or 
more devices; and 

transmitting from the computing device a first result of 
the voting for the first proposed value to the first client, 

wherein the voting for the first proposed value, the 
transmitting the first indication of the voting for the first 
proposed value, and the transmitting the first result are not 
performed if a second message is received at the computing 
device from a second client , the second message comprising 
a second proposed value and a second client identifier 
corresponding to the second client, the second client 
identifier being more dominant than the first client 
identifier and the second proposed value having been 
previously voted for . 



In order for a reference to anticipate this claim, or a set of references to render the claim 
obvious, the recited language and its combination in the recited method must be taught by the 
prior art. The undersigned respectfully submits that the cited references do not teach the 
emphasized language and cannot possibly teach or even suggest the recited method. 

The 085 patent discloses a system wherein a single leader is designated to broadcast 
machine commands and the individual processes vote on the commands. In contrast to claim 
9, the 085 patent does not disclose or suggest "receiving at a computing device from a first 
client a first message comprising a first proposed value and a first client identifier 

corresponding to the first client" and receiving "a second message at the computing 

device from a second client , the second message comprising a second proposed value 
and a second client identifier corresponding to a second client." Rather, in the system 
disclosed in the 085 patent, it appears that messages are received from a single "client," 
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namely the "leader." In other words, the 085 patent does not disclose or suggest receiving a 
first message "from a first client" and receiving a second message "from a second client." 
Indeed, the concept of selecting a leader teaches away from a system wherein messages may 
be received from a plurality of client devices; if there was a leader, messages would not be 
received from a plurality of client devices. 

Moreover, because the 085 patent appears to teach a single leader, and not receiving 
messages from a first client and a second client, the 085 patent cannot possibly teach "not" 
performing "the voting for the first proposed value, the transmitting the first indication of the 
voting for the first proposed value, and the transmitting the first result" if "a second message 
is received . . . the second message comprising a second proposed value and a second 
client identifier corresponding to a second client, the second client identifier being more 
dominant than the first client identifier and the second proposed value having been 
previously voted for." 

The Office also relies upon the Paxos algorithm for the rejection. In contrast to claim 
9, Paxos does not disclose or suggest "receiving at a computing device from a first client a 
first message comprising a first proposed value and a first client identifier 

corresponding to the first client " and receiving "a second message at the computing 

device from a second client , the second message comprising a second proposed value 
and a second client identifier corresponding to a second client ." Rather, in the system 
disclosed by Paxos, proposals are received that are identified by a proposal number. The 
proposal numbers of Paxos do not comprise "a first proposed valued and a first client 
identifier corresponding to the first client" and "a second proposed value and a second 
client identifier corresponding to a second client." 

Furthermore, the Paxos algorithm does not disclose "not" performing "the voting for 
the first proposed value, the transmitting the first indication of the voting for the first 
proposed value, and the transmitting the first result" if "a second message is received . . . the 
second message comprising a second proposed value and a second client identifier 
corresponding to a second client, the second client identifier being more dominant than 
the first client identifier and the second proposed value having been previously voted 
for." Rather, the Paxos algorithm relies on proposal numbers to determine what proposal to 
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execute. Paxos does not determine or consider "the second client identifier being more 
dominant than the first client identifier." Indeed, the concept is entirely absent. 

Therefore, because neither the 085 patent nor Paxos disclose the emphasized claim 
language, even in combination the references cannot be said to disclose or suggest the recited 
combination of claim 9. 



Claim 19 

Claim 19 recites: 

A computing device operating as part of a distributed 
computing system, the computing device comprising: 
a processing unit performing steps comprising: 
comparing at a computer device a first client identifier 
to a second client identifier if a second proposed value, 
proposed in a message receives from a second client and 
comprising the second client identifier and the second 
proposed value , was previously voted for in a first system 
step; and 

voting for a first proposed value in the first system step 
if the first client identifier is more dominant than the second 
client identifier and the second proposed value was previously 
voted for; and 

a network interface performing steps comprising: 

receiving at the computing device from the first 
client a first message comprising the first proposed value 
and a first client identifier corresponding to the first client ; 

transmitting from the computing device a first 
indication of the voting for the first proposed value to one or 
more devices also operating as part of the distributed 
computing system; and 

transmitting from the computing device a first result of 
the voting for the first proposed value to the first client, 

wherein the voting for the first proposed value, the 
transmitting the first indication of the voting for the first 
proposed value, and the transmitting the first result are not 
performed if the second client identifier corresponding to 
the second client is more dominant than the first client 
identifier and the second proposed value has been 
previously voted for . 
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In order for a reference to anticipate this claim, or a set of references to render the claim 
obvious, the recited language and its combination in the recited method must be taught by the 
prior art. The undersigned respectfully submits that the cited references do not teach the 
emphasized language and cannot possibly teach or even suggest the recited method. 

Thus, the 085 patent discloses a system wherein a single leader is designated to 
broadcast machine commands and the individual processes vote on the commands. In 
contrast to claim 19, the 085 patent does not disclose or suggest "receiving at a computing 
device from a first client a first message comprising a first proposed value and a first 
client identifier corresponding to the first client" and receiving "a message . . . from a 
second client and comprisin2 the second client identifier and the second proposed 
value ." Rather, in the system disclosed in the 085 patent, it appears that messages are 
received from a single "client," namely the "leader." In other words, the 085 patent does not 
disclose or suggest receiving a first message "from a first client" and receiving a second 
message "from a second client." Indeed, the concept of selecting a leader teaches away from 
a system wherein messages may be received from a plurality of client devices; if there was a 
leader, messages would not be received from a plurality of client devices. 

Moreover, because the 085 patent appears to teach a single leader, and not receiving 
messages from a first client and a second client, the 085 patent cannot possibly teach "not" 
performing "the voting for the first proposed value, the transmitting the first indication of the 
voting for the first proposed value, and the transmitting the first result" if "the second client 
identifier corresponding to the second client is more dominant than the first client 
identifier and the second proposed value has been previously voted for." 

The Office also relies upon the Paxos algorithm for the rejection. In contrast to claim 
19, Paxos does not disclose or suggest "receiving at a computing device from a first client a 
first message comprising a first proposed value and a first client identifier 

corresponding to the first client" and receiving "a message from a second client and 

comprising the second client identifier and the second proposed value ." Rather, in the 
system disclosed by Paxos, proposals are received that are identified by a proposal number. 
The proposal numbers of Paxos do not comprise "a first proposed valued and a first client 
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identifier corresponding to the first client" and "a second client identifier" "from a 
second client." 

Furthermore, the Paxos algorithm does not disclose "not" performing "the voting for 
the first proposed value, the transmitting the first indication of the voting for the first 
proposed value, and the transmitting the first result" if "the second client identifier 
corresponding to the second client is more dominant than the first client identifier and 
the second proposed value has been previously voted for." Rather, the Paxos algorithm 
relies on proposal numbers to determine what proposal to execute. Paxos does not determine 
or consider "the second client identifier [being] more dominant than the first client 
identifier." Indeed, the concept is entirely absent. 

Therefore, because neither the 085 patent nor Paxos disclose the emphasized claim 
language, even in combination the references cannot be said to disclose or suggest the recited 
combination of claim 19. 



Claim 31 



Claim 31 recites: 

A conflict tolerant message delay reducing consensus 
method for use in a computing environment comprising a at 
least one dedicated client device and a distributed computing 
system implemented by one or more devices, wherein the 
computing system implements the conflict tolerant message 
delay reducing consensus method, the conflict tolerant message 
delay reducing consensus method comprising: 

transmitting one or more proposed values from one 
or more clients , each of the one or more proposed values 
being transmitted in a message comprising one of the one or 
more proposed values and a client identifier corresponding 
to one of the one or more clients ; 

voting, at one or more of the one or more devices 
implementing the distributed computing system, for a proposed 
value from among the one or more proposed values, wherein 
the proposed value was proposed by a client having a most 
dominant client identifier from among the one or more clients 
proposing values; 
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transmitting to one or more of the one or more devices 
implementing the distributed computing system an indication 
of the vote for the proposed value; and 

transmitting, to the client having the highest client 
identifier, a result of the vote for the proposed value 

wherein the voting for the first proposed value, the 
transmitting the indication of the vote for the proposed value, 
and the transmitting the result are not performed if the 
proposed value was proposed by a client not having a most 
dominant client identifier from among the one or more 
clients proposing values . 

In order for a reference to anticipate this claim, or a set of references to render the claim 
obvious, the recited language and its combination in the recited method must be taught by the 
prior art. The undersigned respectfully submits that the cited references do not teach the 
emphasized language and cannot possibly teach or even suggest the recited method. 

Thus, the 085 patent discloses a system wherein a single leader is designated to 
broadcast machine commands and the individual processes vote on the commands. In 
contrast to claim 19, the 085 patent does not disclose or suggest "transmitting one or more 
proposed values from one or more clients , each of the one or more proposed values 
being transmitted in a message comprising one of the one or more proposed values and 
a client identifier corresponding to one of the one or more clients ." Rather, in the system 
disclosed in the 085 patent, it appears that messages are transmitted by a single "client," 
namely the "leader." In other words, the 085 patent does not disclose or suggest transmitting 
"one or more proposed values from one or more clients." Indeed, the concept of selecting a 
leader teaches away from a system wherein messages may be received from a plurality of 
client devices; if there was a leader, messages would not be received from a plurality of 
client devices. 

Moreover, because the 085 patent appears to teach a single leader, and not receiving 
messages from a first client and a second client, the 085 patent cannot possibly teach "not" 
performing "the voting for the first proposed value, the transmitting the indication of the vote 
for the proposed value, and the transmitting the result" if "the voting for the first proposed 
value, the transmitting the first indication of the voting for the first proposed value, and the 
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transmitting the first result" if " the proposed value was proposed by a client not having a 
most dominant client identifier from among the one or more clients proposing values ." 

The Office also relies upon the Paxos algorithm for the rejection. In contrast to claim 
19, Paxos does not disclose or suggest "transmitting one or more proposed values from 
one or more clients , each of the one or more proposed values being transmitted in a 
message comprising one of the one or more proposed values and a client identifier 
corresponding to one of the one or more clients ." Rather, in the system disclosed by 
Paxos, proposals are received that are identified by a proposal number. The proposal 
numbers of Paxos do not comprise "a client identifier corresponding to one of the one or 
more clients ." 

Furthermore, the Paxos algorithm does not disclose "not" performing "the 
voting for the first proposed value, the transmitting the indication of the vote for the proposed 
value, and the transmitting the result" if "the voting for the first proposed value, the 
transmitting the first indication of the voting for the first proposed value, and the transmitting 
the first result" if " the proposed value was proposed by a client not having a most 
dominant client identifier from among the one or more clients proposing values ." 

Rather, the Paxos algorithm relies on proposal numbers to determine what proposal to 
execute. Paxos does not determine or consider " a client not having a most dominant client 
identifier from among the one or more clients proposing values ." Indeed, the concept is 
entirely absent. 

Therefore, because neither the 085 patent nor Paxos disclose the emphasized claim 
language, even in combination the references cannot be said to disclose or suggest the recited 
combination of claim 3 1 . 

Claim 33 

Applicant notes that other claims further define over the references for additional 

reasons. For example, claim 33 recites: 

wherein the dedicated client device is 
identified by a least dominant client 
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identifier . 

The Office cites to the 085 patent for the proposition that the above-reference language of 
claim 33 is anticipated by the following except: "the selection requirement is then satisfied 
by having one of the processes send a message containing its identification number to every 
other process every." Applicant respectfully disagrees. As noted above, the 085 patent relies 
upon a "leader." The 085 patent does not disclose receiving a first message "from a first 
client" and receiving a second message "from a second client." Accordingly, the 085 patent 
does not disclose selecting a proposed value based upon a dominant client identifier. The 
085 patent likewise does not disclose identifying a dedicated client device by a least 
dominant identifier. For this additional reason, the 085 patent does not teach or disclose each 
and every element of claim 33. The Applicant therefore respectfully submits that claim 33 is 
patentable over the 085 patent. 

Reconsideration and withdrawal of the rejections under 35 U.S.C. § 102 and 103 is 
respectfully solicited. 

CONCLUSION 

The undersigned respectfully submits that pending claims are allowable and the 
application is in condition for allowance. A Notice of Allowance is respectfully solicited. 

Examiner Sciacca is invited to call the undersigned in the event a telephone interview 
will advance prosecution of this application. 

Date: December 29, 2008 /John E. McGlynn/ 

John E. McGlynn 
Registration No. 42,863 

Woodcock Washburn LLP 
Cira Centre 

2929 Arch Street, 12th Floor 
Philadelphia, PA 19104-2891 
Telephone: (215) 568-3100 
Facsimile: (215)568-3439 
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